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ABSTRACT: 



A method of scheduling data packets in a multplexer, particulariy in an MPEG-2 server, the 
method comprising the steps of combining a number of packet flows to provide a smaller number 
of flow queues, and operating a scheduling algorithm on the flow queues to select a packet to be 
output The method may also include the step of generating tokens representing the packets and 
the flow queues may then contain the tokens and not the (^icRetsr 
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(54) Multiplexer 

(57) A method of scheduling data packets in a nujl- 
tiplexer, particularly in an MPEG-2 sender, the method 
comprising tiie steps of combining a number of packet 
flows to provide a smaller number of fkiw queues, and 
operating a scheduling algorithm on the f kiw queues to 



select a packet to be output The method may also 
include the step of generating tokens representing the 
packets and tiie flow queues m^ then contain the 
tokens and not the packets. 
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Description 

[0001] This invention relates to the field of muliplexers and, more particularly; to a method and apparatus for imple- 
menting a scheduling algorithm in a multiplexer. 
5 [0002] Scheduling algorithms are used in multiplexers to manage data flow. There are problems inherent in conven- 
tional scheduling algorithms and also problems associated with their implemenlation. This invention is concerned with 
the reduction or elimination of such problems. 

[0003] For example, a group of scheduling algorithms known as packet fair queuing algorithms (PFQ) seek to alkx:ate 
multiplexer output fairly to incoming data packet flows. Fairness is described as the maximum difference t>etween the 
10 normalised service received by two bacMogged flows over an interval in which both are continuously backlogged. Fair- 
ness is desiratDle so that one packet flow does not receive service In preference to others over the tong term. However, 
PFQ algorithms are generally complex. 

[0004] Row Isolation Is desirable in order to prevent flows from being adversely affected by incfividual corrupt pactet 
flows, as this improves multiplexer, and hence network. reliak)ility. It is also desirat)le to keep delay jitter, which is the 
IS maximum difference in delays experienced by any two packets in the same flow, to a minimum. Inevitably, algorithms 
which achieve f kTw isolation and reduce delay jitter are also conplex. 

[0005] However, for a scheduling algorithm to be implemented in either software running on a microprocessor or 
directly in hardware Hs complexity must be limited in order that calculatk>ns can be carried out at a rate suffk:ient to keep 
up with network traffic. Furthermore, the use of large menuxy caches and multiple buffers shoukJ t>e limited in order to 
20 minimise system cost and complexity. 

[0006] The ot>ject of the present invention is to provide efficient, reliable and cost effective implementatk)n of sched- 
uling algorithms having desirat3le charcteristics. 

[0007] According to the present invention there is provided a method of scheduling data packets comprising the steps 
of: 

25 

combining a number of packet flows to provide a smaller number of flow queues: and 
operating a scheduling algorithm on the flow queues to select a packet to be output 

[0008] Preferably, the algorithm is a Fair Queuing algorithm. When the method is used for scheduling data packets in 
30 a MPEG-2 network the algorithm is preferably a Starting Potential based Fair Queuing algorithm. 

[0009] Preferably, the method further comprises tiie step of generating tokens representing the packets and the flow 
queues may then contain the tokens and not the packets. Preferably the tokens comprise a memory address for a 
packet stored in a packet store. 

[0010] Alternatively, the tokens may contain PiD information relating to tiie packet fbws, and tiie mefliod may then 
35 further comprise tiie step of mapping the tokens to the packet flows having the corresponding PID. 

[001 1 ] Any packet flow may be combined with any other packet flow but it is preferable to combine low and high rate 
packet flows such as ttiose for audio and vkieo data. The combined packet flows shouU preferably contain related data 
in order to minimise problenrs associated with the loss of flow isolation. 

[0012] Also according to ttie present Invention there is provided an apparatus for scheduling data packets comprising: 

40 

mapping means for combining a numt)er of packet flows to provide a smaller number of flow queues; and 
controller means for operating a scheduling algorithm on the flow queues to select a packet to be output. 

[001 3] Preferably tiie apparatus further comprises means for generating tokens representing tiie packets and tiie flow 
45 queues may then contain the tokens. Communication between tiie means for generating tokens and the controller 
means may then be over a channel of lower bandwidth than that required for the packet flows and output. 
[0014] The invention includes a multiplexer, an MPEQ-2 server or a network for transmitting data, including the appa- 
ratus for scheduling data packets described above and/or using the method described above. In particular, the invention 
includes an MPEG-2 network Including the apparatus for scheduling data packets described above and/or using the 
so method described above. 

[001 5] An example of tiie present invention will now be described witti reference to tiie accompanying diagrams, in 
which: 

Figure 1 is a flow chart for a scheduler implementing the use of tokens; 
ss Figure 2 is an illustration of flow mapping; and 

Figure 3 is a flow chart of a scheduler implementing tiie use of tokens and flow mapping. 

[001 6] In this example a Starting Potential based Fair Queueing (SPFQ) algorittim is used. This algorithm has desir- 
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able scheduling properties that allow the implementation of. for example, nrtulti-server MPEG-2 networks, txjt it also has 
several complex features difficult to implement in a high speed system. In particular, these include the size of virtual 
time menfx>ry(s) required and the complexity of the virtual time reference and packet selection calculations. The com- 
plexity of the calculations is a f mction of the number of flow queues provided. In an MPEG-2 network this Is governed 
5 by the nuiTt>er of packet identifiers (PIDs) which is a maximum of 8192. Each PID forms a separate packet fk3fw (PID 
f ksw) and hence a separate flow queue. There is therefore a oonpronnise between the number of packet fksws sup- 
ported and the packet processing speed of the multiplexer: 

[0017] SPFQ is a packet fair queueing (PFQ) algorithm suitable for the MPEG-2 network of the present example 
because of its inherent tight delay bounds, fairness, flow isolation and reasonable computational complexity. It is best 
10 implemented in a Reld Progammable Gate Array (FPGA) as this provides fast embedded memay and a parallel 
processing architecture which can be made specif to to the application. hfcTwever, it is not possible to operate at the req- 
uisite packet output rate of 100 Mbitss using conventtonal irrplementatlon techniques. 

[0018] The MPEG-2 systems standard (ISO/IEC 13818-1) specifies a packetised transport stream as the comnfnjni- 
cation medium to convey compressed video, audio and associated service information from source to destination. The 
IS transport stream is conveyed over an MPEG-2 packet network which corrprises of one or more MPEG-2 servers. A 
multiplexer implemented in a MPEG-2 server orders incoming packet flows onto a common oulput link. For the pur- 
poses of describing MPEG-2 packet scheduling the network layers bebw the MPEG-2 packet transport stream are not 
considered. 

[001 9] PFQ algorithms allocate each packet flow a share of the available multiplexer bandwidth. Packets to t>e sched- 
20 uled are given a time stamp relative to a virtual time generated by the algorithm. The time stamps are used to order 
packet selection onto the output link. 

[0020] The time stamp of a SPFQ algorithm comprises a virtual start time and a virtual finish time which is allocated 
to all t>acklogged packets in the scheduler. The start time, Sf^jj, and finish time, F^/j, derived from tfie virtual time. Vj are 
defined as 

S^j^wax{F^j\Vj{4)] 

where a/^ij is tiie arrival time of packet k on scheduler flow queue / (-1^,..M) at multiplexer j (=1,2,..N), and is the 
rate allocated to scheduler flow queue / of multiplexer /. 

[0021 ] The calculation of the finish time can be simplified for the MPEG-2 network as this fias fixed length packets, so 

35 

40 [0022] It can be appreciated that ttie start time S^j is the later (or greater) of the virtual time at the packet arrival and 
the finish time of the previous packet in the same f bw queue. The finish time F^q is simply the start time plus the 
time it takes to remove the packet from the f kMv queue given the rate p,y allocated to tiie packers queue. It should be 
noted tiiat tiie sum of allocated rates must not exceed ttie scheduler resources, ie. 

45 M 

i 



50 where Rj is the scheduler output rate of server y. 
[0023] The virtual time function is expressed. 

55 ^ 

where Vj(t)=0 for t<,0 and B0 is ttie set of backlogged scheduler flow queues. 

[0024] Scheduling can be considered as two processes. Firstiy. on arrival, packets are stored in a flow queue and their 
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IS 



start and finish times are allocated. In order for these times to be allocated, the virtual time must be calculated at the 
time the packet arrives {x=a/^ij-t). 

[0025] Secondly, the packet with the minimum finish time is selected for output by the scheduler. When the selected 
packet is removed the virtual time is updated using the soonest start time of the start times of the packets in the sched- 
uler flow queues. 

[0026] Scheduler flow delay and queue backlog bounds can be described provided a traffic constraint function for the 
traffic flow is known. The preferred model for determining a traff k; constraint functk>n is known as the leaky bucket" 
model. In which the f k)w delay D is expressed as 

N 



where o^^ is the burstiness of the flow prior to the scheduler j. It should also be noted that the burstiness rises monot- 
onically at each multiplexer in the network. Also, the scheduler maximum and minimum latency is expressed 

20 

g^MAX L L 



J 



[0027] Del^ jitter. DJ. is expressed as 

30 ^ ^ 



35 DJ,^^ 



[0028] In order to reduce the number of start and finish times which must be stored, only start and finish times for 
40 packets at the head of a scheduler flow queue (HoQ). which always have the smallest start and finish time in each 
queue, are stored. In other words, as the HoQ packets are always scheduled before any other packet in the same 
queue, only HoQ packet finish times are required by the scheduler to make a scheduling decision. Similarly only HoQ 
start times are required to update the virtual time reference. 

[0029] Conveniently, when a packet Is selected and removed from a queue and the queue is still backlogged, the new 
46 HoQ packet will have a start time equal to the prevk>us packet's finish time as the algorithm will always service a packet 
before the virtual time reference is greater than that packet's finish time. However, when a packet arrives onto an empty 
queue a full calculation is required as the packet may arrive before or after the finish time of the last packet. Hence the 
HoQ start and finish time functions may be defined as 

50 Sy(a*/)=max(Fy(a,V). V^yCaf^-)) if q «(ofj-)=0 

Sy(O=Fy(r-)ifqy(r-)*0 

F,j(t)=S,,(th±^ 

where Sijt)=0 and Fij(t)=0 for t ^0, t- is the instant before f, and t is any packet arrival time, af^fj or packet removal 
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time, f. 

[0030] For simplicity, the full calculation may be used to connpute Sjj when a packet is removed. 
0)031] Tlie set of baddoggedHoQ start and finish times may be written 

10 

[0032] Referring to Figure 1. a flow queue controller 1 nnaintains the flow queues and acts as a HoQ change filter 
outputting a scheduler flow queue signal P when the HoQ packet in queue / changes. A virtual time processor (VTP) 2 
receives the scheduler flow queue signals P and updates the start and finish times when a HoQ change occurs. Only 
15 one HoQ change event can occur per scheduler flow queue per output packet selection. The Virtual time reference con- 
troller 22 updates the virtual time. 

[0033] Row selection is earned out by flow selector 21 . which outputs selection signal r indicating the selected flow 
queue to the flow queue controller 1 . The flow queue controller then initiates removal of the respective packet from the 
head of the selected flow queue, hj". Packet renxsval causes a HoQ change event and the HoQ start, finish and virtual 

20 time reference are again updated as necessary. It can be appreciated that multiple flow queue controllers may be used. 
[0034] It can be appreciated that packet storage and removal in flow queues, determining a HoQ change, updating 
start and f irash times, finding the minimum start and finish time, and timing the period between the last virtual time 
update to a packet arrival or packet selection event all take a finite time to complete. Thus, the data must be held con- 
stant while the calculations are performed. This is achieved by packet store 3, shown in Figure 1 , in which packet anriv- 

25 als k are queued until a release time which occurs periodically. 

[0035] It can be appreciated that as packet anival times are delayed by the packet store 3, the resultant start, finish 
and reference times, and hence packet order, will be different to that of the theoretical case conskJered above, in which 
no account is taken of delays caused by hardware. 

[0036] The interval between release times may conveniently be chosen as the same as the output packet period 
30 T=L/Rj. T is a constant so there is no need to measure packet arrival times precisely As the scheduler is busy transmit- 
ting the outgoing packet during x the packet store 3 does not cause an overall increase in the delay suffered by any 
packet flow provided the interval between release times is less than or equal to the output packet period t. 
[0037] It is important that the f bw queue controller 1 and VTP 2 process incoming packets from the store 3 in time to 
allow for packet selection and virtual time calculation. This must all be done during the time It takes to output a selected 
35 packet 

[0038] In order to improve processing speed, a token is used to indicate the packet arrival. Tokens may be used as 
packet contents are not actually required by the scheduler. In the present example the packet store 3 provides the 
tokens representing packets arriving at the store. 

[0039] Each token uniquely identifies a packet and the tokens and not the packets are stored in the flow queues. Then 
40 a f tow queue is selected by f tow selector 21 , flow queue controller 1 passes a token relating to the head of queue packet 
In the selected flow queue to token controller 4. The token controller 4 then kientifies the packet in the packet store 3 
which conresponds to tiie token, and tiie packet is output in turn, from ttie packet store 3. 

[0040] In this example, a token is a memory location for a corresponding packet in the packet store 3 and the token 
controller 4 simply addresses the packet store 3. However, where there are multiple packet stores 3 the token may also 
45 include a packet store identification information. Alternatively, the token may contain the packet PID and the token con- 
troller uses a token map to identify the packet store memory location for the given the PID. Convenientiy. tokens may 
contain PIDs remapped as they are required to appear in the output transport stream. 

[0041 ] If multiple pactet stores 3 are used, as is often the case, the packet store token output shouU be ordered so 
that the f tow queue controller 1 does not receive simultaneous token arrivals. This may be achieved by using an arbiter 
so to control delivery of tokens from the multiple packet stores. This is not the only way in which tokens may be ordered 
into the flow queue controller 1 , but is advantageous in that tokens from any store can be mapped to any f tow queue 
and a standard multi-drop bus can be used to convey tiie tokens. 

[0042] It is difficult to implement an SPFQ algorithm in present hardware such that it operates wHh sufftoient speed 
and. in particular, with sufficient speed to operate in an MPEG-2 network. Conventional implementation of PFQ algo- 
55 rithms has generally required reduction in the complexity of the algorithm which causes a corresponding reduction in 
the desirable characteristics of fairness, isolation and delay tx)und. 

[0043] The use of tokens is advantageous in that it reduces ttie amount of data transferred to the flow queue controller 
1 and reduces f tow queue storage requirements, tx>th of which reduce implementation complexity without compromis- 
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ing peribrmance. Also, the scheduling algorrthm can be changed or modified without changing the packet store 3. 
[0044] It should be noted that pluraJ VTPs 2 may be used in parallel, all linked to a single flow queue controller 1 . Each 
VTP 2 is allocated a numt)er of fkiw queues and the flow selector 21 selects a flow queue from the results of all the 
VTPs 2. 

[0045] In order to improve the possibility of effective implementation without reducing algorithm complexity, the 
number of packet flows operated upon can be reduced or the speed of the search function of the f k3w selector 21 which 
selects the minimum finish time F^fj can be improved. It is. of course, undesirable to reduce the number of packet flows 
operated upon, as this inevitably reduces the amount of data the multiplexer can handle. 

[0046] Schemes to improve search function speed, such as those using tree structures or more advanced structures 
like the stratified trees are complex and difficult to implement in hardware. In this example a linear minimum search 
scheme is employed. 

[0047] However, even if the linear mininum search is fast, it is unlikely that calculatton speed will be improved suffi- 
ciently for the multiplexer of the present example to operate In an MPEG-2 network. A technique called flow mapping is 
therefore employed to reduce the number of scheduler flow queues. Flow mapping involves the mapping of packets 
from one or more input packet flows to the same scheduler flow queue. 

[0048] Referring to Rgure 2. in an MPEG-2 network, flow mapping allows different PID f bws to share the same sched- 
uler flow queue. It is required that each packet f kiw must map to only one scheduler f tow, although many input packet 
flows can be mapped to the same scheduler f tow queue. A f tow map controller 5 is therefore provided between packet 
store 3 and flow queue controller 1 . The f tow map controller 5 of the present example comprises a PID de-muftiplexer 
51 for mapping the packet into f tow queues (illustratively shown as 52 in Rgure 2). 

[0049] Ftow mapping is advantageous in that it allows a realistic number of scheduler f tow queues to be provided with- 
out restricting tfie number of schedulable PlDs (ie. packet f tows). It also allows the delay bound of an indivklual input 
PID flow to be reduced and allows statisttoally nuiltiplexed PID flows, that have a constant group rate, to be efficiently 
multiplexed. 

[0050] It must, however, be noted that, by grouping packet flows into one scheduler flow queue the isolation t^etween 
the packet flows is lost. Thus, if a packet flew becomes corrupt it will affect the delay and packet loss suffered by other 
packet ftaws sharing the same scheduler ftow queua Row mapping must therefore be implemented carefully For 
example, in an MPEG-2 network, corresponding audto arxJ video packet f tows may be grouped together. 
[0051 ] The number of scheduler ftow queues and how the packets are mapped determines the maximum number of 
PlD's that can be scheduled. In an MPEGr2 networK a 100 Mbitss'^ transport stream may contain 50 video/audio serv- 
ices and a similar number of information data streams. With the packet flews corresponding to the same service 
mapped to the same scheduler ftow queue, the number of ftow queues provkied by a basic scheduler shouM t>e 1 00 to 
200 flow queues. In other words, if each service has around 4 to 8 PIDs around 400-1600 PIDs can t>e scheduled. 
[0052] With flow mapping a scheduler flow queue comprises many packet ftaws so for leal^ bucket modelled streams 
the new constraint function, A*ij, is expressed as 



where g is the ind^ of packet f tows and Gfj is the set of packet flows mapped to scheduler flow queue / at scheduler j. 
[0053] The delay for a scheduler ftow queue is now expressed as 



Z <'gj-^ 

[0054] The allocated rate. Pij, should be greater than or equal to the sum of the rates of input f tows mapped to sched- 
uler flow /. 

[0055] As the allocated rate, p/j, for the scheduler ftow / is going to be higher than the rate of the packet ftow. r^, then 
we notice a key feature of flow mapping, namely that the delay, backlog and jitter bounds of a packet flow can be 
reduced when it is grouped with other packet flows. It is easy to show that Ds+tj^Daj and hence DJ^^j^DJ^j when the 
following condition exists, 
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5 [0056] Audio flows are low in rate so the number of remuftipiex stages before the jitter limits specified by MPEQ-2 are 
violated is low. One way to reduce the delay bound and hence packet jitter is to over allocate scheduler rate to audio 
flows. However this reduces output utilisatton. The alternative provided by flow mapping is to map audio f tows to the 
same queue as a high rate flow. In MPEG-2 transport streams a suitable high rate flow is the associated GBR video 
flow. As the video rate is sigrdf icantiy higher than the audio rate, without significantly different burstiness, there is a sig- 

10 nificant reduction in delay tx)und tor the audio component allowing the flow to traverse more remultiplex stages. It can 
be appreciated that if an audio flow is associated with the video flow at every multiplexer in a network this advantage 
will be optimised. 

[0057] Considering, fa example, a 192Kbrtss'^ audio flow, the minimum receiver multiplex buffer, hence allowable 
delay jitter tor audio f tows, is 736 bytes or 4 packets. Given a source burstiness of one packet and at each stage tiie flow 
IS is allocated a rate equal to the long term arrival rate then three remultiplex stages are possible. However if the audio 
flow were mapped in with a 1 Mbitss'** video flow then 8 remultiplex stages are possible. 

[0058] For the implementation, a way of mapping packet flow indices, g, to scheduler flow queue indices / is required. 
As described above, the packet store 3 produces tokens which provide unique identification of packets in the packet 
store 3, and a token to scheduler flow queue map is also provided. If the tokens contain packet PIDs then the map is 
20 convenientiy a PID to scheduler f tow queue index map. It shouM. however, be noted that if the token is just a memory 
location tiiis map would be more complex. Including the packet PID in the token allows the PID to flow queue mapping 
process to be periormed with the token from the packet store 3 as shown in Figure 3. 

[0059] The flow map controller 5 outputs the token so it can be stored by the f tow queue conlroner 1 in a scheduler 
flow queue /. Advantageously, a shared bus may support multple packet stores 3 provided a token to flow queue map 
25 is provided for each f tow queue controller 1 . However, as the P ID to packet flow association is fatriy static the flow map- 
ping function could be integrated with the packet store 3 to remove the need for a flow map controller and schediJer 
flow queue information included with the token. 

[0060] Row mapping also altows the multiplexing of statistically controlled f tows to be implemented effectively. 
[0061 ] Statistically controlled flows are rate controlled flows an-anged into groups by a controller so that the total group 

30 bit rate is constant. The members of the group have ttieir rate adjusted to maintain constant data quality. Each flow 
therefore has a pseudo-variable rate witti a maximum bit rate approaching tiie group maximum. 
[0062] A problem encountered when implementing a multiplexer handling statistically controlled ftows is ttiat traffto 
flow models, such as the leaky bucket model described above, require a tong term packet flow rate parameter for each 
packet flow to estin^te delay bounds. However, as described atx}ve, although the statistically controlled ftow has a 

35 more or less continuous rate, each individual packet flow of the statistically controlled flow has a continuously varying 
rate. Row mapping according to the present invention allows all the packet ftows of a statistically controlled flow to be 
grouped to one scheduler flow queue, and thus only the more or less continuous rate of the group needs to be consid- 
ered to estimate the delay bound. Also, as ftow mapping is used the indivkJual packet ftows will have lower delay kxxjnds 
than if tiiey were treated indivtoually (see above). 

40 [0063] Rnally. it is desiraldle to separate the packet store 3 and tiie other incoming packet flow functions from tiie cal- 
culation functions of VTP 2, ftow controller 1 , flow selector 21 and virtual time reference controller 22. The use of tokens 
between the packet store arxi flow queue controller 1 minimises the bandwidth of the channel between these two sec- 
ttons of tiie scheduler and this channel can thus be a propriety or standard bus interfoce such as PCI. 

45 Claims 

1 . A mettiod of scheduling data packets comprising the steps of: 

combining a number of packet flows to provide a smaller number of flow queues; and 
50 operating a scheduling algorithm on the flow queues to select a packet to be output. 

2. The method of claim 1 , wherein the step of operating a scheduling algorithm comprises operating a Fair Queuing 
algorithm. 

55 3. The method of claim 2. wherein the step of operating a Fair Queuing algorithm comprises operating a Starting 
Potential based F^r Queuing algoritiim. 

4. The method of any of claims 1 to 3. further comprising the step of generating tokens representing the packets and 
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wherein the flow queues contain the tokens. 

5. The method of claim 4, wherein the step of generating tokens comprises generating tokens which comprise a mem- 
ory address for a packet stored in a packet store. 

5 

6. The method of daim 4. wherein the step of generating tokens comprises generating tokens comprising PID infor- 
mation relating to the packet f ksfws. 

7. The method of claim 6, further comprising the step of mapping the tokens to the packet flows having the corre- 
10 sponding RID. 

8. The method of any of the preceding claims, wherein the step of combining a number of packet flows comprises 
combining a low rate packet f bw with a high rate packet flow to form a flow queue. 

15 9. The method of any of the preceding claims, wherein the step of combining a numt>er of packet flows comprises 
combining packet flows of related data to provide a flew queue of related data. 

10. The method of claim 8 or 9, wherein the step of combining packet ftows comprises combining one packet flow of 
audio data and another packet f tow of corresponding vkleo data. 

1 1 . An apparatus for scheduling data packets comprising: 

mapping means for combining a number of packet flows to provide a smaller number of flow queues; and 
controller means for operating a scheduling algorithm on the flow queues to select a packet to be output. 

12. The apparatus of daim 1 1 . wherein the algorithm Is a Fair Queuing algorithm. 

13. The apparatus of daim 12, wherein the algorithm is a Starting Potential t>ased Fair Queuing algorithm. 

30 14. The apparatus of any of claims 11 to 13, further comprising means for generating tokens representing the packets 
and wherein the flow queues contain the tokens. 

15. The apparatus of claim 14, wherein the mapping means and controller means are connected by a channel of lower 
bandwkfth than the channel required for the packet flow and output. 

35 

16. The apparatus of claims 14 or 15, wherein the tokens comprise a menrK>ry address for a pactet stored in a packet 
stora 

17. The apparatus of daims 14 or 15, wherein the tokens contain PID inlbrmatton relating to the packet flows. 

40 

18. The apparatus of daim 1 7. further comprising means lor mapping the tokens to the packet flows having the corre- 
sponding PID. 

1 9. The apparatus of any of claims 1 1 to 1 8, further comprising means for comt)lning a low rate packet flow with a high 
45 rate packet f tow to form a flow queue. 

20. The apparatus of any of daims 1 1 to 19, wherein data carried by packet flows of a flow queue is related. 

21 . The apparatus of daim 1 9 or 20, wherein one packet flow is for audio data and another packet f tows is for corre- 
50 sponding video data. 

22. A nrultiplexer including the apparatus of any of claims 1 1 to 21 . 

23. An MPEQ-2 server induding the apparatus of any of claims 1 1 to 21 . 

55 

24. A network for transmitting data including the apparatus of any of claims 1 1 to 21 . 

25. An MPEG-2 network induding the apparatus of any of claims 1 1 to 21 . 
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